In February, 2000, SyncML initiative was created to synchronize personal information or corporation data between multiple platforms and networks. The objective of creating the SyncML initiative was to make a user, a device manufacturer, a basic component developer, a data provider, an application developer and a service provider cooperate with each other, and enable network data to be accessed by any client anywhere at any moment.
A typical application of the SyncML initiative is the data synchronization between a mobile device and a network service device. Besides the above-mentioned application, the SyncML initiative is applicable to the data synchronization between two equivalent devices, such as two computers. The data synchronization of a client and a server includes the following processes. After a negotiation of device information at an initialization phase of the synchronization, the client sends the data changed by the client to the server for storing, and the server sends the data changed by the server to the client for storing, so as to guarantee the data synchronization between the client and the server.
At present, there are mainly several sync types shown in Table 1.
TABLE 1Type of synchronizationDescription informationTwo-way syncA normal sync type in which the client and the server exchange information about modified data in these devices, and information about data not being modified is not exchanged in these devices. The client sends the modifications first.Slow syncA special form of two-way sync in which all items are compared with each other on a field-by-field basis. In practice, this means that the client sends all its data from a datastore to the server andt he server does the sync analysis (field-by-field) for the data received from the client and the data stored in the server itself.One-way sync A sync type in which the client sends modifications from client onlyof the client to the server but the server does not send modifications of the server back to the client.Refresh sync This type of sync is a one-side sync in which the client from client onlysends all its data from a datastore to the server; and the server replaces all data corresponding to the client in the server with the data sent by the client.One-way sync A sync type in which the client gets all modifications from server onlyfrom the server but the client does not send its modifications to the server.Refresh sync This type of sync is similar to the type of Refresh sync from server onlyfrom client only, and in this type of sync the server sends a client all data corresponding to the client and stored in the server, the client replaces all data in the client with the data sent by the server, that is the data in the client is same as the data corresponding to the client and stored in the server.Server Alerted A sync alert type, which provides the means for a syncserver to alert the client to perform synchronization. When the server alerts the client, it also tells the client which type of synchronization to initiate, and type of the following synchronization may be one ofthe above mentioned types of synchronization.
How to perform data synchronization is hereinafter described by taking the two-way sync as example. Other sync types are special cases of the two-way sync. For example, the slow sync is the two-way sync in which both client and server can send out all the data of the user; one-way sync is the two-way sync in which the data of the user is sent in one way; refresh sync is the slow sync in which the data of the user is sent in one way.
Two-way data sync between a server and a client includes the following steps.
In step 1, a client sends a synchronization initialization package to a server.
In step 2, the server sends the synchronization initialization package to the client.
In step 1 and step 2, a synchronization initialization is performed. The synchronization initialization includes the following processes: authentication, synchronization data negotiation, device information negotiation, etc. The device information negotiation determines what data format can be synchronized, and which synchronization types are supported.
In step 3, the client sends synchronization data to the server.
In step 4, the server sends synchronization data to the client.
In step 3 and step 4, the client sends changed data to the server based on change state of the data. And the change state of the data may be Add, Update, Delete, Move, etc. The server modifies the data stored in the server according to the data received from the client, so that the server fulfils the data synchronization. And the server also sends the changed data to the client based on the change state of data stored in the server, and the client modifies the data stored in the client according to the data received from the server, so that the client fulfils the data synchronization.
In step 5, after receiving the synchronization data, the client sends a synchronization acknowledgement message to the server.
In step 6, after receiving the synchronization data, the server sends synchronization acknowledgement message to the client.
The message package may be used in the above-mentioned steps. And an interaction with the same function between the client and the server should be performed several times by exchanging several messages within one message package, before the interaction is completed. Two message packages, i.e. one sending package and one receiving package, may be used to express the interaction.
The system for data synchronization includes the client and the server which interact with each other to exchange information. On client side, there may be also a database for storing the data needed by a user. The client database can be set in the client or can be set separately. On server side, there may be also another database for storing the data of the server. The server database can be set in the server or can be set separately.
In general, the client can be an intelligent terminal, such as a computer, a mobile terminal or a Personal Digital Assistant (PDA). The data stored in the database at the client side may include: contacts, calendars, notes, Emails, etc. There may be standard data formats for all of the above data. The client can convert the stored data into standard data format, and send the converted data to the server. After the received data is processed by the server, the server may store the processed data into the database at the server side.
In general, the server can be a computer or a network server performing data synchronization. And the server can receive a data synchronization message or a data synchronization command from the client; or the server can send a data synchronization message or a data synchronization command to the client.
FIG. 1 shows a data table of the data stored in the client database. Each data item is identified by a Local Unique Identifier (LUID). Each LUID can be unique for a type of data, or for a client. And each data item has a Change Log recording data status, i.e., the Status shown in FIG. 1.
FIG. 2 shows a data table of the data stored in the server database. Each data item may be identified by a Global Unique Identifier (GUID) of the data synchronization network. And a mapping table is set up to record mapping relations between GUID and LUID for the same data item.
The interaction between the client and the server can result in a change of data item status of the data in the client database or the server database. The client and the server can determine what kind of data synchronization instruction or/and data synchronization message may be received according to the changes of data item status of the data in the client database and server database respectively.
The data synchronization instruction or/and data synchronization message sent from the client to the server include: <Add>, which indicates that the client sends new data item and LUID thereof to the server, then the server adds the data item sent from the client into the server database, and creates a GUID for the data item sent from the client and stores a mapping relation between the LUID and GUID of the data item sent from the client; <Update>, which indicates that the client sends updated data item and LUID thereof to the server, then the server finds out a corresponding GUID of the LUID according to a mapping relation stored, updates the data corresponding to the GUID and stores the updated data; <Delete>, which indicates that the client sends LUID for the data item to be deleted to the server, then the server finds out a corresponding GUID of the LUID according to a mapping relation stored, deletes the data item corresponding to the GUID and removes the mapping relation between the LUID and GUID from a mapping table; <Move>, which indicates that the client sends an original LUID and a destination LUID of the data item to be moved to the server, then the server finds out an original GUID corresponding to the original LUID and a destination GUID corresponding to the destination LUID, and moves the data corresponding to the original GUID to the data item corresponding to the destination GUID.
The data synchronization instruction or/and data synchronization message sent from the server to the client include: <Add>, which indicates that the server sends new data item and GUID thereof to the client, then the client adds the data item sent from the server into the client database, and creates a LUID for the data item sent from the client and returns a newly-created LUID to the server; <Update>, which indicates that the server sends updated data item and LUID thereof to the client, then the client updates the data item corresponding to the LUID, and stores the updated data; <Delete>, which indicates that the server sends LUID for the data item to be deleted to the client, and removes a mapping relation of the LUID and the GUID from a mapping table, then the client deletes the data item corresponding to the LUID; and <Move>, which indicates that the server sends an original LUID of the data item and a destination LUID of the data item to be moved to the client, then the client moves data corresponding to the original LUID to the data item corresponding to the destination LUID.
At present, anchors may be used for indicating the latest successful data synchronization session between a client and a server. Anchors may be used in the server database or client database, i.e., when the data synchronization is completed between the client and the server, the same anchor may be created in the client database and the server database. When another data synchronization is initiated later, the client or the server shall first check whether the anchor in the client database is identical with the anchor in the server database. And if the anchor in the client database is identical with the anchor in the server database, normal data synchronization will be performed; otherwise a slow sync or a refresh sync will be initiated.
The process of updating the anchor between the client and the server includes the following steps:
Step 1: A client sends a synchronization data package to a server, and the synchronization data package carries synchronization data, last anchor for the last synchronization session, and next anchor for the present synchronization session.
Step 2: Upon receiving the synchronization data package, the server compares the last anchor sent from client with the last anchor in the server database, if the received last anchor is identical with the last anchor stored in the server database, the server synchronizes data of the server with the synchronization data carried by the synchronization data package, updates the anchor in the server database in accordance with the anchor carried by the synchronization data package for the present synchronization session, and returns a synchronization data package carrying the synchronization data to the client. The synchronization data includes the data identified as modified in the server database; if the last anchor in the package is different from the anchor in the server database, the server initiates a slow sync or a refresh sync.
When there is slow sync between the client and the server, the client has to send all data in the client database to the server, and the server shall compare every data item of the client database with corresponding data item in the server database. At present, the slow sync may be initiated due to the following reasons. The first reason is that the LUIDs in the client database are out of order or lost, the re-use of LUID by the client or the re-creature of LUID would make the LUIDs out of order, thus the LUID-GUID mapping table in the server becomes useless, and the client and the server are unable to determine how data items in databases correspond to each other. The second reason is that the Change Log in the client database is lost, so it becomes impossible to tell which data item has been synchronized and which data item still needs to be synchronized. The third reason is that the anchors of the client and the server are different from each other, even when the client initiates a fast synchronization, the server would still find that the anchors of the client and the server are different from each other, thus the client and the server would not know whether the data of the server and the client are synchronized, then a slow sync has to be initiated.
For the first or second reason described above, the client may be initiate a slow sync on its own initiative; and for the third reason, the client initiates a slow sync on its own initiative, or the server requests the client to initiate the slow sync.